Subject: AIW 11 - DLSW Minutes

From: Paul Brittain <[email-masked]>
Date: Wed, 24 Jul 1996 14:35:26 +0100

Apologies - the RTF usage by my mailer seems to have caused the first
post of AIW11 minutes to come out strangely formatted when they were
mailed back to me from aiw-dlsw.  

I hope this re-post will have cured the problem and made it easier for
you all to read.

Paul.

-----------------------------------------------

>Here are the minutes for the DLSw RIG meeting at AIW 11 last week.  
>
>In summary, most of the discussion focused on the scalability document
>and the steps needed to expand this to a full v1.1 document.  Although
>we did not grant formal AP to this document, it is expected that this
>will be achieved on the mailer in the near future.  We will be seeking
>CP for the final v1.1 document at AIW 12.
>
>As usual I have not minuted all the minor spelling etc corrections to
>the document for sake of clarity on the more important functional
>points.  However, all such editorial mark-ups will be incorporated in
>the next release of the document.
>
>If anyone has any queries/corrections to the detailed minutes that
>follow, please post them or mail them to me.
>
>Thanks,
>
>Paul Brittain.
>
>
>RFC 1795 clarifications
>=======================
>
>Roger of Walldata raised the issue that some exsting implementations
>appear to ignore circuit setup frames (not data frames) sent to them
>immediately after the transport connection is established, but not if
>he adds a 1 second pause before starting to send traffic.  After some
>discussion it was concluded that although such behaviour is clearly
>undesirable/incorrect, no clarification to 1795 is required.  To the
>origin DLSw, this case is indistinguishable from when the traget simply
>fails to respond to the circuit setup because of resource shortage.
>
>The other clarifications discussed in previous meetings will be
>incorporated in an appendix to the v1.1 document.
>
>Multicast vs unicast UDP
>========================
>
>A lengthy discussion followed on how to incorporate unicast UDP usage
>into the scalability document.  It was felt that there is benefit in
>allowing Unicast to a (known) group of partners, for example when the
>set of partners that can reach an address is already cached.  However,
>all v1.1 implementations must support use of at least the default
>multicast group (in particular receipt on this address) for the case
>when the partner DLSw addresses are not already known and to ensure
>interoperability.
>
>Use of unicast traffic exclusively is not permitted as this breaks the
>scalability problems that the RIG set out to solve.
>
>It was decided that the changes to the current document to allow this,
>and to clarify when unicast/multicst/TCP should be used were not that
>great and were deferred to the detailed document review that followed.
>
>Document review
>===============
>
>Overall the document was thought to be in good shape.  The detailed
>functional comments/issues are listed below by section number.
>
>5.1:
>----
>
>The UDP address range reserved for DLSw was partitioned as follows:
>
>	224.0.10.0-63	-	Reserved for AIW use
>	224.0.10.64-255	-	Available for customer/vendor use.
>
>6.1:
>----
>
>The streamlined method for bringing up one TCP pipe between partners
>given at the end of this section was found to be insufficiently
>detailed for interoperability.  After considerable discussion both at
>this point, at the end of the document review, and the Wednesday
>morning, it was felt that the RFC 1795 mechanism will work, but a more
>efficient mechanism should be sought to avoid some of the WAN traffic
>implicit in 2xTCP pipe bring-ups if such a proposal can be agreed in
>time for v1.1.  Cisco are to post a proposal in the next 2 weeks.  If
>the proposal is too late or concensus cannot be reached, it was not
>felt worth delaying v1.1 over this issue.
>
>6.3:
>----
>
>The UDP/TCP port numbers should be decimal throughout this document.
>
>6.3.1:
>------
>
>While is is not strictly necessary for all implementations to
>immediately change their SSP parsing logic as described here (as we
>have not yet made use of any new SSP formats), failure to do so will
>hamper future interoperability.  This section will be reworded in the
>final v1.1 document to clarify why this is needed, and moved to the
>section covering the vendor-specific SSP frame formats. 
>
>6.3.2:
>------
>
>Remove the restriction that UDP unicast can only be used when no TCP
>pipe exists.  Add a new section (6.5) to describe when TCP vs UDP
>unicast/multicast  should be used.
>
>6.4:
>----
>
>Reword this section to clarify that use of UDP unicast is useful
>supplement to using multicast, but it is recommended that unicast is
>only used when the group of partner DLSw addresses is known.  The
>mechanisms by which this information may be learnt or configured is
>outside the scope of this paper.
>
>All implementation must be capable of supporting receipt of explorer
>traffic on the default multicast group address.
>
>7:
>--
>
>The 'back-level' terminology is confusing and should be changed to
>refer to 'multicast-capable' vs 'non-multicast'.
>
>7.1:
>----
>
>Add the reason code value for rejection of a cap-ex if the multicast
>support flag is set but the partner does not support single-pipe TCP
>operation.
>
>7.3:
>----
>
>Remove the note from this section and the 'in practice' discussion. 
>There was also discussion over whether it was necessary to exchange a
>reason code with the partner before closing a TCP pipe in order that
>the partner e.g. to distinguish tme-out of an unused peer-on-demand
>connection from a network error.  However, the concensus was that the
>effort required will not be justified by the benefits gained.
>
>8:
>--
>
>Add a table for SNA messages like that in 9 for Netbios, and remove the
>list of messages in 8.2.
>
>8.5.1:
>------
>
>Recommend that retries of responses are NOT used even if they are sent
>unicast.
>
>9:
>--
>
>NAME_QUERY and STATUS_QUERY should be unicast/multicast.  Notes 1 and 3
>should have the TCP reference removed.
>
>9.4:
>----
>
>as per 8.5.1.
>
>
>Other work items:
>=================
>
>Multicast peer discovery:
>-------------------------
>
>After the document review there was a short discussion on discovery of
>peers via multicast as a separate option to RFC1795 from the
>scalability enhancements.  This will reduce the config requirements for
>non-multicast implementations and possibly provide a mechanism to
>address the concerns about loss of function from the cap-ex that the
>existing proposal implies.
>
>John of IBM will look into this and the original cap-ex issue and post
>a proposal.  It is unlikely that this wil make 1.1, but this was not
>thought to be a problem.
>
>Flow control:
>-------------
>
>Dave bryant (3COM) raised a concern that the per-circuit flow control
>logic n RFC1795 may prove to be a scalability problem as the CPU load
>for large numbers of circuits increases.  This item was taken no
>further at this meeting.
>
>Future work:
>------------
>
>Proposals are still invited on the following topics for v1.2 or later
>versions:
>
>-	reducing the size of Netbios SSP headers
>-	loop prevention
-	other transports
>-	HPR support
>-	APPN Discovery architecture support
>-	any other enhancements of interest.
>
>It is suggested (by the editor) that we identify at the next meeting
>what further work this RIG wishes to undertake and to what timescales.
>
>
V1.1 Document Structure
=======================

The v1.1 document will form a set of enhancements to RFC 1795 and will
be published as a separate RFC that does not obsolete 1795.  The
document will consist of the current scalability document plus new
sections covering

-	vendor-specific SSP formats
-	RFC 1795 clarifications
-	single tunnel bringup (if available in time).

Section 1-4 of the existing document will be edited to reflect the
>widened scope of the document.

AIW 12:
=======

This RIG requested 8 hours at the next AIW.